4.2 Interactive Debugging

Debugging failed tests essentially works the same way as debugging any other problems with Lisp code. Here are a few tricks specific to tests:

• Re-run the failed test a few times to see if it fails in the same way each time. It’s good to find out whether the behavior is deterministic before spending any time looking for a cause. In the ERT results buffer, r re-runs the selected test.
• Use . to jump to the source code of the test to find out exactly what it does. Perhaps the test is broken rather than the code under test.
• If the test contains a series of should forms and you can’t tell which one failed, use l, which shows you the list of all should forms executed during the test before it failed.
• Use b to view the backtrace. You can also use d to re-run the test with debugging enabled, this will enter the debugger and show the backtrace as well; but the top few frames shown there will not be relevant to you since they are ERT’s own debugger hook. b strips them out, so it is more convenient.
• If the test or the code under testing prints messages using message, use m to see what messages it printed before it failed. This can be useful to figure out how far it got.
• You can instrument tests for debugging the same way you instrument defuns for debugging: go to the source code of the test and type C-u C-M-x. Then, go back to the ERT buffer and re-run the test with r or d.
• If you have been editing and rearranging tests, it is possible that ERT remembers an old test that you have since renamed or removed: renamings or removals of definitions in the source code leave around a stray definition under the old name in the running process (this is a common problem in Lisp). In such a situation, hit D to let ERT forget about the obsolete test.